codex: allow-list --profile by subcommand; omit it where codex rejects it#184
codex: allow-list --profile by subcommand; omit it where codex rejects it#184Edwinhe03 wants to merge 1 commit into
Conversation
c577f42 to
bcff2ab
Compare
bcff2ab to
7d540fb
Compare
|
am i testing this right? it seems to error on start? i checked out your branch no app-server: with app-server |
|
|
follow up: |
7d540fb to
a9961a2
Compare
…s it ucode's codex launch always ran `codex --profile ucode <args>`, but codex only accepts the global `--profile` on runtime subcommands (the interactive TUI, exec/review/resume/archive/delete/unarchive/fork/mcp/sandbox). Server-family subcommands (app-server, mcp-server, exec-server, remote-control) and utilities reject it up front: Error: --profile only applies to runtime commands and `codex mcp`: ... so e.g. `ucode codex app-server` was functionally broken. Allow-list the subcommands that accept `--profile` (a deny-list would break the next codex server subcommand by default) and attach it only for those. For the rest, omit `--profile` and pass the caller's args through untouched — those subcommands are caller-configured (e.g. omnigent runs `codex app-server` with its own CODEX_HOME), so ucode just stays out of the way. Co-authored-by: Isaac
a9961a2 to
b37ab3d
Compare
| _CODEX_GLOBAL_VALUE_FLAGS = frozenset( | ||
| { | ||
| "-c", | ||
| "--config", | ||
| "-i", | ||
| "--image", | ||
| "-m", | ||
| "--model", | ||
| "-p", | ||
| "--profile", | ||
| "-s", | ||
| "--sandbox", | ||
| "-C", | ||
| "--cd", | ||
| "-a", | ||
| "--ask-for-approval", | ||
| "--enable", | ||
| "--disable", | ||
| "--remote", | ||
| "--remote-auth-token-env", | ||
| "--local-provider", | ||
| "--add-dir", | ||
| } | ||
| ) |
There was a problem hiding this comment.
will we need to maintain this list whenever codex updates their cli ?
| _CODEX_PROFILE_SUBCOMMANDS = frozenset( | ||
| {"exec", "review", "resume", "archive", "delete", "unarchive", "fork", "mcp", "sandbox"} | ||
| ) |
There was a problem hiding this comment.
will we also need to maintain this list ? it also will depend on the cli version of codex that the customer is on
There was a problem hiding this comment.
yes, I can't see how we can get around this. but problem statement is ucode unconditionally adds --profile to all codex commands when codex doesn't support --profile on all subcommands. do you have any ideas?
What
ucode codex's launch always rancodex --profile ucode <args>. But codex only accepts the global--profileon runtime subcommands (the interactive TUI,exec/review/resume/archive/delete/unarchive/fork/mcp/sandbox). Server-family subcommands (app-server,mcp-server,exec-server,remote-control) and utilities reject it immediately:So
ucode codex app-server(and the other server subcommands) was functionally broken.Change
--profile(a deny-list would break the next codex server subcommand by default; the allow-list fails safe) and attach it only for those.--profileand pass the caller's args through untouched. Those are caller-configured — omnigent runscodex app-serverwith its ownCODEX_HOME, and ucode's config isn't even read whenCODEX_HOMEis set — so ucode just stays out of the way rather than injecting a named profile codex won't accept.Scoped to the minimum: just the
--profileguard in the codex agent (_codex_subcommand+ the allow-list). No config-override machinery, no passthrough.Verification
ruff+tyclean.codex app-server --listen …(no--profile) binds cleanly.codex --profile ucode execstill works (runtime subcommand).codex app-server --profile ucodereproduces the original error (negative control).This pull request and its description were written by Isaac.